Service convergence across multiple communication domains

ABSTRACT

A computer-implemented method for communication includes assigning to at least first and second communication terminals ( 22 ) of a communication system ( 20 ) at least respective first and second private identities and a common public identity different from at least the first and second private identities. Registrations of the public identity and of at least the first and second private identities are simultaneously maintained in the communication system ( 20 ). A request is received to set up a call in which the public identity serves as one of a source and a destination of the call. The call is established between a third communication terminal and one of at least the first and second communication terminals ( 22 ) using the simultaneously-maintained registrations.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication 60/645,024, filed Jan. 21, 2005, which is incorporatedherein by reference.

FIELD OF THE INVENTION

The present invention relates generally to communication networks, andparticularly to methods and systems for providing communication servicesacross multiple communication domains.

BACKGROUND OF THE INVENTION

Several concepts and architectures are known in the art for providingcommunication services over communication networks. For example, theIntelligent Network (IN) is an architectural concept that enablesreal-time execution of network services and customer applications in adistributed environment of interconnected computers and switchingsystems, such as wireline and wireless telephone networks. IN standardshave been promulgated by the International Telecommunications Union(ITU-T) and by the American National Standards Institute (ANSI). The INconcept is described, for example, by Faynberg et al., in “TheDevelopment of the Wireless Intelligent Network (WIN) and Its Relationto the International Intelligent Network Standards,” Bell Labs TechnicalJournal, Summer, 1997, pages 57-80, which is incorporated herein byreference.

Another example of a standardized service provisioning architecture isthe Internet Protocol Multimedia Subsystem (IMS) architecture. The IMSarchitecture is defined and described in a 3rd Generation PartnershipProject (3GPP) standard entitled “Technical Specification Group Servicesand System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 7),”3GPP TS 23.228, version 7.2.0, December 2005. This standard is availableat www.3gpp.org/ftp/Specs/html-info/23228.htm. The IP multimedia corenetwork (IM CN) subsystem enables Public Land-Mobile Network (PLMN)operators to offer their subscribers multimedia services based on andbuilt upon Internet applications, services and protocols.

The IMS architecture is described, for example, in a whitepaperpublished by Lucent Technologies Inc. (Murray Hill, N.J.) entitled “IPMultimedia Subsystem (IMS) Service Architecture,” February, 2005, whichis incorporated herein by reference. The whitepaper is also available atwww.lucent.com/livelink/090094038005df2f_White_paper.pdf.

SUMMARY OF THE INVENTION

In many practical situations, a service provider or other organizationoperates two or more communication networks conforming to differentstandards, protocols or access methods. For example, a service providermay operate both wireline and wireless networks, or may be in theprocess of migrating from a legacy network to a new-generation network.In such applications, it is often desirable to converge and unify theservices provided by these networks, as well as the management ofsubscribers and communication terminals. Embodiments of the presentinvention provide methods and systems for service-level convergence ofcommunication networks.

In some cases, a subscriber may operate two or more communicationterminals, or may operate dual-mode or multi-mode terminals. Methods andsystems described herein converge and unify the services provided tosubscribers, regardless of the particular terminal or network used toobtain these services. In some embodiments, two or more communicationterminals are associated with a common public identity. Each terminal isalso associated with a unique private identity. Records that registerboth public and private identities are maintained simultaneously by theservice provider. Calls related to the public identity are thenprocessed using the simultaneously-maintained registration records.

In some embodiments, services carried out by service platforms indifferent communication networks are invoked and offered to a terminal,regardless of the network affiliation of the terminal. In particular,services carried out by service platforms in networks conforming todifferent communication domains are invoked and provided during a singlecall or session.

In some practical scenarios, a circuit-switched network is connected toa packet-switched network. In some embodiments, the convergence methodsand systems described herein enable calls arriving over thepacket-switched network and addressed to terminals of thecircuit-switched network to be routed to their destinations withoutusing any gateway switching elements of the circuit-switched network,such as gateway MSCs. As a result, traffic load and processing tasks aretransferred from the circuit-switched network to the packet-switchednetwork and the routing of calls is simplified.

There is therefore provided, in accordance with an embodiment of thepresent invention, a computer-implemented method for communication,including:

assigning to at least first and second communication terminals of acommunication system at least respective first and second privateidentities and a common public identity different from at least thefirst and second private identities;

simultaneously maintaining registrations of the public identity and ofat least the first and second private identities in the communicationsystem;

receiving a request to set up a call in which the public identity servesas one of a source and a destination of the call; and

establishing the call between a third communication terminal and one ofat least the first and second communication terminals using thesimultaneously-maintained registrations.

In an embodiment, the first communication terminal communicates with afirst network conforming to a first communication domain, and the secondcommunication terminal communicates with a second network conforming toa second communication domain different from the first communicationdomain.

In another embodiment, establishing the call includes invoking a firstservice platform in the first network to provide a first call serviceand invoking a second service platform in the second network to providea second call service, the first and second call services associatedwith the public identity.

In yet another embodiment, receiving the request includes receiving anincoming call destined to a subscriber associated with the publicidentity, and establishing the call includes selecting a terminal fromamong the first and second communication terminals and routing theincoming call to one of the first and second private identities that isassigned to the selected terminal.

In still another embodiment, routing the incoming call includes routingthe incoming call to the selected terminal via a convergence server (CS)in the communication system.

Additionally or alternatively, routing the incoming call includesassigning to the received incoming call a first temporary routablenumber (TRN) associated with the CS in order to cause the incoming callto be routed to the CS. Further additionally or alternatively, routingthe incoming call includes assigning to the incoming call routed to theCS a second. TRN so as to cause the incoming call to be routed from theCS to the selected terminal.

In an embodiment, assigning the first TRN includes caching at the CS anassociation between the first TRN and the public identity and, when theincoming call routed to the CS does not carry the public identity,determining the public identity responsively to the cached association.

In another embodiment, receiving the request includes receiving anoutgoing call initiated by an initiating terminal including one of thefirst and second communication terminals, the outgoing call addressed toa destination, and establishing the call includes routing the outgoingcall to the destination via a convergence server (CS) in thecommunication system.

In yet another embodiment, routing the outgoing call includes replacingin the outgoing call a private identity of the initiating terminal withthe public identity.

Additionally or alternatively, routing the outgoing call via the CSincludes assigning to the received outgoing call a temporary routablenumber (TRN) associated with the CS, so as to cause the outgoing call tobe routed to the CS, and subsequently routing the outgoing call from theCS to the destination.

Further additionally or alternatively, assigning the TRN includescaching at the CS an association between the assigned TRN and one of thefirst and second private identities associated with the initiatingterminal, and, when the outgoing call routed to the CS does not carrythe private identity of the initiating terminal, determining the privateidentity of the initiating terminal responsively to the cachedassociation.

In an embodiment, establishing the call includes invoking a call serviceassociated with the public identity. In another embodiment, establishingthe call includes handing-off the call from the one of the first andsecond communication terminals to another of the first and secondcommunication terminals.

There is also provided, in accordance with an embodiment of the presentinvention, a convergence server (CS), including:

a registry, which is arranged to hold an association between at leastfirst and second private identities of at least respective first andsecond communication terminals and a common public identity differentfrom at least the first and second private identities; and

a processor, which is arranged to store in an identity database aregistration of the public identity in addition to registrations of atleast the first and second private identities stored in the identitydatabase, so as to cause the identity database to simultaneouslymaintain the registrations of the public identity and of at least thefirst and second private identities, to receive a request to set up acall in which the public identity serves as one of a source and adestination of the call, and to establish the call between a thirdcommunication terminal and one of at least the first and secondcommunication terminals responsively to the association and to thesimultaneously-maintained registrations.

There is further provided, in accordance with an embodiment of thepresent invention, a communication system, including:

an identity database;

at least first and second communication terminals having at leastrespective first and second private identities registered in theidentity database; and

a convergence server, which is arranged to assign to at least the firstand second communication terminals a common public identity differentfrom at least the first and second private identities, to cause theidentity database to simultaneously maintain registrations of the publicidentity and of at least the first and second private identities, toreceive a request to set up a call in which the public identity servesas one of a source and a destination of the call, and to establish thecall between a third communication terminal and one of at least thefirst and second communication terminals responsively to the associationand to the simultaneously-maintained registrations.

There is additionally provided, in accordance with an embodiment of thepresent invention, a computer software product for communication, theproduct including a computer-readable medium, in which programinstructions are stored, which instructions, when read by a computer,cause the computer to hold an association between at least first andsecond private identities of at least respective first and secondcommunication terminals and a common public identity different from atleast the first and second private identities, to store in an identitydatabase a registration of the public identity in addition toregistrations of at least the first and second private identities storedin the identity database so as to cause the identity database tosimultaneously maintain the registrations of the public identity and ofat least the first and second private identities, to receive a requestto set up a call in which the public identity serves as one of a sourceand a destination of the call, and to establish the call between a thirdcommunication terminal and one of at least the first and secondcommunication terminals responsively to the association and to thesimultaneously-maintained registrations.

There is also provided, in accordance with an embodiment of the presentinvention, a computer-implemented method for communication in acommunication system including a circuit-switched network and apacket-switched network, the method including:

accepting a request to set up a call for a communication terminalassociated with one of the circuit-switched network and thepacket-switched network;

establishing the call with the one of the circuit-switched network andthe packet-switched network responsively to the request; and

during the call, invoking a first service platform in thecircuit-switched network to provide a first call service, and a secondservice platform in the packet-switched network to provide a second callservice to the communication terminal.

In an embodiment, the circuit-switched network operates in accordancewith a signaling system 7 (SS7) protocol.

In another embodiment, the first service platform includes a servicecontrol point (SCP) and the first service includes an intelligentnetwork (IN) service.

In yet another embodiment, the packet-switched network includes anInternet Protocol (IP) network, and the second service platform includesa session initiation protocol (SIP) application server (AS).

In still another embodiment, the packet-switched network includes an IPMultimedia Subsystem (IMS) network.

There is additionally provided, in accordance with an embodiment of thepresent invention, a convergence server, including:

first and second network interfaces, which are respectively arranged tocommunicate with a circuit-switched network and a packet-switchednetwork; and

a processor, which is arranged to accept a request to set up a call fora communication terminal associated with one of the circuit-switchednetwork and the packet-switched network, to establish the call with theone of the circuit-switched network and the packet-switched networkresponsively to the request and, during the call, to invoke a firstservice platform in the circuit-switched network to provide a first callservice, and a second service platform in the packet-switched network toprovide a second call service to the communication terminal.

There is further provided, in accordance with an embodiment of thepresent invention, a communication system, including:

a circuit-switched network including a first service platform, which isarranged to provide a first call service;

a packet-switched network including a second service platform, which isarranged to provide a second call service; and

a convergence server connected to the circuit-switched andpacket-switched networks, which is arranged to accept a request to setup a call for a communication terminal associated with one of thecircuit-switched network and the packet-switched network, to establishthe call with the one of the circuit-switched network and thepacket-switched network responsively to the request and, during thecall, to invoke the first and second service platforms in order toprovide the first and second call services to the communicationterminal.

There is also provided, in accordance with an embodiment of the presentinvention, a computer software product for communication, the productincluding a computer-readable medium, in which program instructions arestored, which instructions, when read by a computer, cause the computerto communicate with a circuit-switched network including a first serviceplatform arranged to provide a first call service, to communicate with apacket-switched network including a second service platform arranged toprovide a second call service, to accept a request to set up a call fora communication terminal associated with one of the circuit-switchednetwork and the packet-switched network, to establish the call with theone of the circuit-switched network and the packet-switched networkresponsively to the request and, during the call, to invoke the firstand second service platforms in order to provide the first and secondcall services to the communication terminal.

There is additionally provided, in accordance with an embodiment of thepresent invention, a computer-implemented method for communication overcircuit-switched and packet-switched networks, including:

accepting, at a media gateway controller (MGC) connected to thecircuit-switched and packet-switched networks, signaling of a calladdressed to a destination terminal in the circuit-switched network;

responsively to the signaling, interrogating a home location register(HLR) of the circuit-switched network without using any gatewayswitching element of the circuit-switched network so as to provide tothe MGC routing information enabling routing of the call to a servingswitching element of the circuit-switched network that serves thedestination terminal; and

based on the provided routing information, routing the call using theMGC to the destination terminal via the serving switching element.

In an embodiment, the circuit-switched network includes a mobilecircuit-switched network.

In another embodiment, the method includes accepting a media content ofthe call at a media gateway (MGW) controlled by the MGC and connected tothe circuit-switched and packet-switched networks, and routing the callincludes causing the MGW to route the media content to the destinationterminal via the serving switching element.

In yet another embodiment, interrogating the HLR includes accepting fromthe HLR a temporary routable number (TRN) associated with the servingswitching element, and routing the call includes causing the MGC toroute the call to the TRN.

In still another embodiment, the circuit-switched network includes firstand second sub-networks including respective first and second HLRs, andinterrogating the HLR includes determining one of the first and secondsub-networks with which the destination terminal is associated, andinterrogating a corresponding one of the first and second HLRs.

In an embodiment, the first sub-network conforms to a firstcommunication protocol and the second sub-network conforms to a secondcommunication protocol different from the first communication protocol.

In another embodiment, interrogating the HLR includes accepting from theHLR an indication of a call service to be provided to the call, andinvoking a service platform to provide the call service.

In yet another embodiment, invoking the service platform includesinvoking at least one of a service control point (SCP) in thecircuit-switched network and an application server (AS) in thepacket-switched network.

In still another embodiment, interrogating the HLR includes acceptingfrom the HLR an indication of a call service including a routingoperation to be performed on the call, and performing the routingoperation responsively to the indication.

There is further provided, in accordance with an embodiment of thepresent invention, a convergence server, including:

a network interface, which is arranged to communicate with acircuit-switched network, a packet-switched network and a media gatewaycontroller (MGC) connected to the circuit-switched and packet-switchednetworks; and

a processor, which is arranged to interrogate a home location register(HLR) of the circuit-switched network responsively to signaling of acall accepted by the MGC over the packet-switched network, the calladdressed to a destination terminal in the circuit-switched network soas to provide to the MGC, without using any gateway switching element ofthe circuit-switched network, routing information enabling routing ofthe call to a serving switching element of the circuit-switched networkthat serves the destination terminal and, based on the provided routinginformation, to route the call using the MGC to the destination terminalvia the serving switching element.

There is also provided, in accordance with an embodiment of the presentinvention, a communication system, including:

a circuit-switched network;

a packet-switched network;

a media gateway controller (MGC) connected to the circuit-switched andpacket-switched networks, which is arranged to accept signaling of acall over the packet-switched network, the call addressed to adestination terminal in the circuit-switched network, and to route thecall to the destination terminal; and

a convergence server connected to the MGC and to the circuit-switchedand packet-switched networks, which is arranged to interrogate a homelocation register (HLR) of the circuit-switched network responsively tothe signaling of the call without using any gateway switching element ofthe circuit-switched network, so as to provide to the MGC routinginformation enabling routing of the call to a serving switching elementof the circuit-switched network that serves the destination terminal,and, based on the provided routing information, to route the call usingthe MGC to the destination terminal via the serving switching element.

There is additionally provided, in accordance with an embodiment of thepresent invention, a computer software product for communication overcircuit-switched and packet-switched networks, the product including acomputer-readable medium, in which program instructions are stored,which instructions, when read by a computer, cause the computer tointerrogate a home location register (HLR) of the circuit-switchednetwork responsively to signaling of a call accepted by a media gatewaycontroller (MGC) over the packet-switched network, the call addressed toa destination terminal in the circuit-switched network, so as to provideto the MGC, without using any gateway switching element of thecircuit-switched network, routing information enabling routing of thecall to a serving switching element of the circuit-switched network thatserves the destination terminal and, based on the provided routinginformation, to route the call using the MGC to the destination terminalvia the serving switching element.

The present invention will be more fully understood from the followingdetailed description of the embodiments thereof, taken together with thedrawings in which:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram that schematically illustrates a communicationsystem, in accordance with an embodiment of the present invention;

FIG. 2 is a block diagram that schematically illustrates elements of aconvergence server, in accordance with an embodiment of the presentinvention;

FIG. 3 is a diagram that schematically illustrates public and privateidentities, in accordance with an embodiment of the present invention;

FIG. 4 is a call-flow diagram that schematically illustrates a methodfor registration with a mobile network, in accordance with an embodimentof the present invention;

FIG. 5 is a call-flow diagram that schematically illustrates a methodfor registration with a packet network, in accordance with an embodimentof the present invention;

FIG. 6 is a flow chart that schematically illustrates a method forprocessing incoming calls, in accordance with an embodiment of thepresent invention;

FIG. 7 is a flow chart that schematically illustrates a method forprocessing outgoing calls, in accordance with an embodiment of thepresent invention;

FIGS. 8A and 8B are block diagrams that schematically illustratedistributed gateway mobile switching center (GMSC) configurations, inaccordance with embodiments of the present invention;

FIG. 9 is a call-flow diagram that schematically illustrates a methodfor processing an incoming call using a distributed GMSC configuration,in accordance with an embodiment of the present invention;

FIGS. 10-14 are call-flow diagrams that schematically illustrate methodsfor processing incoming and outgoing calls, in accordance withembodiments of the present invention; and

FIGS. 15 and 16 are call-flow diagrams that schematically illustratemethods for handing-off calls, in accordance with embodiments of thepresent invention.

DETAILED DESCRIPTION OF EMBODIMENTS System Description

FIG. 1 is a block diagram that schematically illustrates a communicationsystem 20, in accordance with an embodiment of the present invention.System 20 provides connectivity as well as various communicationservices to communication terminals 22. System 20 comprises two or morenetworks conforming to respective communication domains. Eachcommunication domain is characterized by a particular standard, protocolor access method. For example, in the configuration of FIG. 1, system 20comprises a circuit-switched mobile network 24 and a packet-switchednetwork 28, each viewed as a separate communication domain. Typically,the communication domains of system 20 are different from one another.In some embodiments, however, system 20 may comprise two communicationdomains conforming to the same standard, protocol or access method.

In alternative embodiments, the communication domains of system 20 maycomprise, for example, Wireless Local Area Networks (WLAN), Wi-Finetworks, WiMax Networks, Code Division Multiple Access (CDMA) networkssuch as CdmaOne, CDMA2000 and EvDo, Global System for Mobilecommunication (GSM) networks, Universal Mobile Telecommunication System(UMTS) and other third generation (3G) networks, IP Multimedia Subsystem(IMS) networks, wireline networks of different kinds, or any othersuitable communication networks. The communication domains may compriseeither circuit-switched or packet-switched networks.

System 20 may comprise any number of communication domains, which aretypically but not necessarily operated by the same service provider. Themethods and systems described hereinbelow enable the service provider toconverge and unify the services provided by system 20, as well as tomanage the subscribers and terminals across the different communicationdomains of the system.

Terminals 22 conduct calls via network 20. Although the embodimentsdescribed herein refer mainly to voice calls, in the context of thepresent patent application and in the claims, the term “call” is used ina wider sense to describe any type of communication session with aterminal 22, such as, for example, voice calls, short message service(SMS) messages, multimedia messaging service (MMS) messages, SIP instantmessages, IP connections, voice over IP sessions and multimediasessions.

In the exemplary configuration of FIG. 1, mobile network 24 providesconnectivity and services to cellular terminals 32, such as cellularphones, cellular modems and adapters, and/or any other type of cellularterminals. For the sake of simplicity, the description that follows willrefer mainly to cellular phones, although the methods and systemsdescribed herein can be used in conjunction with any other type ofcellular terminals and wireless communication clients.

Cellular phones 32 register with one or more mobile switching centers(MSC) 36, typically via base stations and base station controllers (notshown), as is known in the art. In some cases, a particular MSC mayperform the function of a gateway MSC (GMSC) that accept incoming callsfrom outside of network 24, as a serving MSC(S-MSC) serving a particularphone 32, or both.

A home location register (HLR) 40 serves as the main identity databaseof network 24. HLR 40 stores subscriber and terminal information, suchas the identities of the subscribers and terminals used in system 20. Insome embodiments, HLR 40 may store access privileges, service parametersand any additional information related to the subscribers and/orterminals of system 20. As will be shown below, HLR 40 has a centralrole in determining how calls are routed to and from a particularcellular phone.

In some embodiments, the functions of HLR 40 described herein can becarried out by any other suitable network element comprising an identitydatabase, which is interrogated by incoming and/or outgoing calls. Thus,HLR 40 in this context is an exemplary embodiment of an identitydatabase.

In some embodiments, network 24 provides intelligent network (IN)services, as are known in the art. As such, network 24 comprises one ormore service control points (SCP) 44. Generally, each SCP comprises anetwork element that receives triggers from an MSC or other networkelement and provides a particular communication service. IN services maycomprise, for example, toll-free (“1-800”) services, charging/billingservices or prepaid services. Network 24 may also comprise additionalelements known in the art, such as a short message service (SMS) center48.

In the exemplary configuration of FIG. 1, the elements of network 24 areinterconnected by a circuit-switched public land mobile network (PLMN)operating in accordance with the well-known signaling system 7 (SS7)protocol. Network 24 may be logically divided into a switching layer,which comprises the MSCs, and a service layer, which comprises the HLR,SCPs and SMS center.

Packet network 28 operates in accordance with the well-known sessioninitiation protocol (SIP). Network 28 provides connectivity andcommunication services to IP terminals 52 such as SIP phones, voice overIP (VoIP) phones, IP multimedia terminals and/or any other type of IPterminals. For the sake of simplicity, the description that follows willrefer mainly to SIP phones, although the methods and systems describedherein can be used in conjunction with any other type of IP terminal.

In some embodiments, network 28 operates in accordance with the IMSarchitecture cited above. Like network 24, network 28 can also belogically divided into a switching layer (also referred to as a sessioncontrol layer) and a service layer. In the switching layer, inaccordance with the SIP protocol, a call state control function (SCSF)56 serves as a database that registers and authenticates SIP phones 52and handles session control for these phones. Active SIP phonestypically register with the CSCF. The CSCF is thus able to provide aroutable address, such as an IP address, with which the SIP phone iscurrently associated. In some embodiments, the CSCF comprises astandalone network element. In alternative embodiments, thefunctionality of the CSCF can be integrated into other network elements,as will be explained below. In the service layer of network 28, one ormore SIP application servers (AS) 60 provide particular communicationservices.

The two communication domains (networks 24 and 28) are connected by oneor more media gateways (MGW) 64 controlled by media gateway controllers(MGC) 68. Media gateways, as are known in the art, are located at theedge of a multi-service packet network and provide media translationbetween the protocols of disparate networks, such as between networks 24and 28. For example, in the configuration of FIG. 1, MGW 64 translatesthe time division multiplexing (TDM) media formats of network 24 intoIP-formatted media as required in network 28, and vice versa. MGC 68(sometimes also referred to as a Softswitch) provides translation ofsignaling and control protocols between the communication domains. Inthe example of FIG. 1, MGC 68 translates between the SS7 and SIPprotocols used by networks 24 and 28, respectively.

MGW 64 and MGC 68 provide media and control translation, both related tothe switching layer of networks 24 and 28. However, in order to providefull service-level unification of the two networks, it is desirable toprovide convergence and translation at the service level. Theseservice-level convergence functions are performed by a convergenceserver (CS) 72, which is connected to networks 24 and 28, and typicallyalso to MGC 68. The internal structure of CS 72, as well as methods foridentity management, call processing and service unification carried outusing CS 72, are described below.

Although the network configuration of FIG. 1 and some of the methoddescriptions hereinbelow refer to the service-level convergence of anSS7 network with a SIP network, various other types of communicationdomains that can be converged will be apparent to those skilled in theart. For example, the methods and systems described herein can be usedto provide service-level convergence for dual-mode or multi-modeterminals 76, which support two or more communication domains in asingle user terminal. As another example, IP network 28 may comprise aWLAN network that provides services to wireless SIP terminals. Network24 may comprise, for example, a wireline SS7 network comprising othertypes of switching elements, such as C4/C5 switches.

FIG. 2 is a block diagram that schematically illustrates elements ofconvergence server 72 and their interaction with elements of system 20,in accordance with an embodiment of the present invention. In the systemconfiguration of FIG. 2, MGC 68 is also connected to a public switchedtelephone network (PSTN) 78, from which incoming calls may arrive and towhich outgoing calls may be destined. CS 72 comprises a control module80, which performs the different management and coordination functionsof the server. These functions are sometimes referred to as servicecapability interaction management (SCIM) functions. Module 80 alsoserves as a network interface for communicating with CSCF 56 and withSIP application servers 60 of network 28. In alternative embodiments,the functions of CSCF 56 may be integrated as part of CS 72 or MGC 68.

A service switching function (SSF) 84 serves as a network interface forcommunicating with SCPs 44 of network 24. The SSF produces triggers thatinvoke the different SCPs to provide the required services. Inembodiments in which network 24 conforms to the IN architecture, SSF 84communicates with SCPs 44 using IN application protocol (INAP). SSF 84also interrogates HLR 40 as part of the call processing methodsdescribed below. A service control function (SCF) 88 serves as aninterface with MSCs 36 of network 24. Typically, the SCF interacts withthe MSCs similarly to a SCP.

CS 72 comprises a CS registry 92, which serves as a visitor locationregister (VLR) for subscribers of system 20. CS 72 also comprises aredirection proxy 96, which stores contexts of calls processed by CS 72.The roles of registry 92 and proxy 96 will be explained in greaterdetail in the method descriptions further below.

Typically, convergence server 72 comprises a general-purpose computer,which is programmed in software to carry out the functions describedherein. The software may be downloaded to the CS in electronic form,over a network, for example, or it may alternatively be supplied to thecomputer on tangible media, such as CD-ROM.

Management of Multiple Identities

In many cases, a particular subscriber may own or operate two or moreterminals 22 of system 20. For example, the same subscriber may operatea cellular phone 32, a WLAN-enabled laptop computer comprising asoftware-based voice over IP (VoIP) client and a wireline SIP phone 52,all registered with the service provider of system 20. As anotherexample, a subscriber may use a dual-mode terminal 76, which has bothcellular and WLAN functionalities. In the present context, the dual-modeterminal is viewed as two separate terminals 22—a cellular phone 32 anda WLAN terminal—packaged together. Another example of multiple terminalsassociated with a single subscriber is a multi-mode wireless terminalintegrating CDMA, GSM and Wi-Fi terminals.

In general, each of the terminals operated by the subscriber isassociated with one of the communication domains of system 20, such asmobile network 24 or packet network 28. The methods and systemsdescribed herein converge and unify the services provided by system 20to the subscriber, regardless of the terminal he or she currently usesto obtain these services.

In particular, it is often desirable that the subscriber be identifiedto other subscribers by a single identity, regardless of the terminal 22currently used. This subscriber identity, referred to as a public ID,typically comprises the telephone number by which the subscriber isknown (e.g., the number given on the subscriber's business card or aSIP-based Uniform Resource Identifier (URI) address). Thus, incomingcalls destined to the subscriber will carry the public ID as thedestination of the call. Outgoing calls originating from any of theterminals operated by the subscriber should carry the public ID as thesource of the call. The public ID is usually created when the subscriberfirst signs up with the service provider.

As will be shown below, the public ID carried by outgoing and incomingcalls is sometimes used to invoke outgoing call services (O-sideservices) and/or incoming call services (T-side services) associatedwith the subscriber. As such, O-side and T-side services are invokedregardless of the terminal 22 used in the call. Additionally, when therecipient of an outgoing call initiated by the subscriber usescaller-ID, the ID displayed will be the public ID. Additionally oralternatively, other actions related to the subscriber and not to aparticular terminal 22, such as billing and customer care, are performedusing the public ID.

In addition to the subscriber-related public ID, each terminal 22 isuniquely identified by a private ID. In some embodiments, theassociation between public IDs and private IDs is stored and managed inthe convergence server. Alternatively, the association can also bestored and/or managed in a suitable external database accessible to theconvergence server. Typically, the private ID comprises a networkaddress of the terminal, in accordance with the technology, standard orprotocol of the communication domain in question.

For example, the private ID of a particular cellular phone 32 maycomprise an International Mobile Station Identity (IMSI) orInternational Mobile Equipment Identity (IMEI), as used in GSM and UMTSnetworks. In an IP network, the private ID of a SIP terminal maycomprise a SIP address of the terminal. Other examples of private IDsare Mobile Identification Numbers (MIN) used in some CDMA networks andSIP URIs used in some SIP-based packet networks. The private ID istypically recognized only internally in system 20. Users and/or externalelements and networks communicating with the subscriber, as well as thesubscriber himself, are usually only aware of the public ID and not ofthe private IDs.

FIG. 3 is a diagram that schematically demonstrates the concept ofpublic and private identities, in accordance with an embodiment of thepresent invention. A subscriber 79 is identified by a public ID. In thepresent example, subscriber 79 uses three terminals 22. SIP phone 52used by subscriber 79 is associated with packet network 28 and isidentified by a private ID denoted PRIVATE ID1. Subscriber 79 alsooperates a dual-mode terminal 76, which may communicate with both mobilenetwork 24 and packet network 28. The cellular terminal in dual-modeterminal 76 is identified by a private ID denoted PRIVATE ID2, whereasthe SIP terminal in the dual-mode terminal is identified by a private IDdenoted PRIVATE ID3. Cellular handset 32 used by subscriber 79 isassociated with mobile network 24 and is identified by a private IDdenoted PRIVATE ID4. All four private IDs are associated with the samepublic ID.

The private IDs of terminals 32 of network 24 that are currentlyaccessible in network 24 are registered in HLR 40. The private IDs ofterminals 52 that are currently accessible in network 28 are typicallystored in a database accessible to the convergence server, such as in anetwork-specific registry in network 28 or in registry 92, as will bedescribed below. An exemplary network-specific registry may comprise ahome subscriber server (HSS) used in IMS networks. In general, therecord registering the private ID points to a network location whereinformation for accessing the corresponding terminal 22 is available.When terminal 22 belongs to mobile network 24, the record points to theMSC that currently serves this terminal. When terminal 22 belongs topacket network 28 the record points to CSCF 56.

In addition, the public ID related to the subscriber is registered inHLR 40 using a record that points to convergence server 72. The recordregistering the public ID in the HLR defines CS 72 (or, more accurately,registry 92 of CS 72) as the VLR of the public ID. In other words, CS 72is configured as the serving MSC(S-MSC) of all public IDs. Exemplaryregistration processes, in which the appropriate registration recordsare created and stored, are described in FIGS. 4 and 5 below.

Thus, when an incoming call carrying a certain public ID arrives, theHLR routes the call to CS 72, as indicated by the record correspondingto this public ID. In some cases, when the incoming call is destined toa public ID in the form of a SIP URI address, the call will be routed tothe CS 72 via CSCF 56. CS 72 selects the private ID to which the callshould be routed, and performs the appropriate routing. An exemplarymethod for processing incoming calls is described in detail in FIG. 6below. The method description includes several exemplary criteria andlogic, which may be applied by CS 72 for selecting the private ID.

When an outgoing call is initiated by one of the terminals associatedwith a certain public ID, the call is routed to CS 72. CS 72 replacesthe private ID carried by the call with the public ID and routes thecall to its destination. An exemplary method for processing outgoingcalls is described in detail in FIG. 7 below.

Unlike some known identity management methods in which only one privateidentity is registered (i.e., active) at any given time, in the methodsand systems described herein all private IDs associated with aparticular public ID can be active simultaneously. The simultaneousavailability of multiple private IDs provides several advantages.

For example, a hand-off process from one private ID to another (i.e.,the process of transferring an active call from one terminal to another)is quick and smooth, in comparison to known hand-off procedures. In someembodiments, when simultaneous private identities are activesimultaneously, the corresponding terminals 22 are also kept active.Therefore, unlike known hand-off procedures, there is no need to performterminal initialization as part of the hand-off process. Additionally,there is no need to deregister one private ID and to register anotherprivate ID in the HLR or to qualify the terminal with the HLR.Furthermore, the hand-off procedure can be made: transparent to theservice platforms (e.g., SIP AS and/or SCP) involved in the call. Sincethere is no need to register and deregister the private IDs, thesignaling load handled by HLR 40 is reduced. Exemplary hand-offprocedures that use simultaneously-active private identities aredescribed in FIGS. 15 and 16 below.

The simultaneous availability of private IDs enables CS 72 to exercisedifferent rules or policies when deciding to which terminal an incomingcall is to be routed. For example, in some embodiments it is possible tosend an indication of the call (e.g., session/call ring) to allterminals 22 associated with the public ID, not only to the terminalselected to accept the call. As another example, different call/sessiontypes can be routed to appropriate terminal types. For example, when onecommunication domain of system 20 comprises a cellular network andanother domain comprises a data network (e.g., EvDO or WiFi) that doesnot support voice media, voice calls can be routed to a terminal of thecellular network, while messaging calls can be routed to a terminal ofthe data network, assuming both terminals are associated with the samepublic ID.

Registration Method Descriptions

FIG. 4 is a call-flow diagram that schematically illustrates a methodfor registering a cellular phone 32 in mobile network 24, in accordancewith an embodiment of the present invention. The call flow examplesgiven below use the terminology of the IS-41 network standard, which istypical of US cellular networks such as CDMA. Call flows that usesimilar principles can be defined for any other suitable networkstandard, such as GSM.

The registration method begins with cellular phone 32 being turned oninside the coverage area of mobile network 24, or otherwise attemptingto join the mobile network. Phone 32 first registers with one of MSCs 36using its private ID, at a phone MSC registration step 100. The MSC withwhich the phone registers is referred to as the serving MSC, or S-MSC,of this phone.

The serving MSC sends a registration notification (REGNOT) messagecomprising the phone's private ID to HLR 40, at a phone HLR registrationstep 101. The registration notification message of step 101, carryingthe private ID, is also received by convergence server 72, at aregistration interception step 102. In some embodiments, the CS monitorsthe registration messages using a passive probe mechanism or using aproxy mechanism, as are known in the art. A proxy mechanism typicallycomprises using an active element acting as an HLR towards the MSCs andas an MSC towards the HLR. Steps 102, 104 and 105 below are optional andapplicable when probing/proxy methods are used. Otherwise, registrationof the public ID in step 104 below is performed as a static or periodicprovisioning process.

If the registering phone 32 is authorized by ILR 40, the HLR creates andstores a record comprising the private ID of the cellular phone andpointing to the serving MSC. The HLR then sends a registration approvalmessage to the serving MSC, at a HLR MSC approval step 103. The approvalmessage typically comprises service parameters to be used for thisterminal. In particular, the approval message notifies the MSC that CS72 is to be used as SCP for this terminal.

In some embodiments, after receiving the registration notificationmessage at step 102 above, control module 80 of CS 72 retrieves fromregistry 92 the public ID that corresponds to the private ID carried bythe notification message. CS 72 then sends a registration notificationmessage to HLR 40, at a cellular CS HLR registration step 104. Themessage requests the HLR to register the public ID with a recordpointing to the CS (i.e., requesting to define the CS as the VLR of thepublic ID).

In an alternative embodiment, CS HLR registration step 104 is performedonly after HLR 40 authorizes the terminal and registers thecorresponding private ID (i.e., after a successful completion of HLR MSCapproval step 103 above). After the HLR registers the public ID, itsends an approval message to the CS, at a cellular HLR CS approval step105. Additionally or alternatively, before carrying out step 104, CS 72may first check whether the public ID is already registered in the HLR(for example because another terminal 22 associated with this public IDis already registered). If the public ID is already registered, steps104 and 105 are omitted.

In some embodiments, public IDs are also registered in SIP applicationservers 60 in parallel to the registration in the HLR. In theseembodiments, CS 72 sends a SIP registration message to SIP AS 60, at acellular SIP registration step 106. The SIP application servers registerthe public ID and approve the SIP registration message, at a cellularSIP approval step 107.

After the registration method described above is completed, two recordsare added to the HLR: (1) the cellular phone's private ID is registeredwith a record pointing to the serving MSC and (2) the correspondingpublic ID is registered with a record pointing to the CS.

If additional terminals 32 (and optionally other terminals 52)associated with this public ID are also active, the private IDs of theseterminals will also be registered in the HLR using additional,mutually-independent records. The use of these records in the processingand routing of incoming and outgoing calls is shown in FIGS. 6 and 7below.

FIG. 5 is a call-flow diagram that schematically illustrates a methodfor registering a SIP terminal with packet network 28, in accordancewith an embodiment of the present invention. The method begins with aSIP terminal, for example a SIP phone, attempting to join network 28.The SIP terminal sends a registration message to CSCF 56 using itsprivate ID, at a terminal CSCF registration step 108. The CSCF registersthe SIP terminal's current IP address.

CSCF 56 now sends a registration message to CS 72, at a CSCF CSregistration step 109. The CS accepts the message carrying the privateID and retrieves the corresponding public ID from registry 92. The CSthen registers the public ID at SIP application servers 60 and at HLR40. In some embodiments, the CS accepts from CSCF 56 a routable addressof the SIP terminal, such as an IP address or a SIP Uniform ResourceIdentifier (URI) of the terminal. The CS stores the routable address ofthe SIP terminal and uses it to route subsequent incoming calls destinedto the terminal.

Optionally, CS 72 also sends a registration message to AS 60, at aterminal AS registration step 110. The SIP application servers registerthe public ID with a record pointing to the CS, and approve theregistration message, at an AS CS approval step 111.

CS 72 sends a registration message to HLR 40, at a SIP CS HLRregistration step 112. The message requests the HLR to register thepublic ID with a record pointing to the CS (i.e., requesting to definethe CS as the VLR of the public ID). After the HLR registers the publicID, it sends an approval message to the CS, at a SIP HLR CS approvalstep 113. Having completed the registration process, CS 72 approves theregistration to CSCF 56, at a CS CSCF approval step 114. CSCF 56 in turnapproves the registration to the SIP phone, at a CSCF terminal approvalstep 115.

When the process described above is completed, the HLR comprises anadditional record registering the public ID and pointing to the CS. TheSIP application servers also comprise a similar record. The CSCFcomprises a record registering the private ID of the SIP terminal, aswell as a routable address of the SIP terminal. In some embodiments, theroutable address is also stored in the CS. The use of these records inthe processing and routing of incoming and outgoing calls is shown inFIGS. 6 and 7 below.

Processing of Incoming and Outgoing Calls

FIG. 6 is a flow chart that schematically illustrates a method forprocessing incoming calls arriving into system 20, in accordance with anembodiment of the present invention. Generally, the method describes thefollowing sequence of actions, performed in system 20 in response to anincoming call: (1) determine the terminals (private IDs) that correspondto the public ID provided in the call, (2) determine to which of theprivate IDs the call is to be routed and (3) route the call to itsappropriate destination.

The exemplary method of FIG. 6 refers to an incoming call carrying apublic ID that corresponds to two terminals 22, namely a cellular phone32 and a SIP phone 52. The method can be adapted in a straightforwardmanner to process incoming calls for different types of communicationdomains and terminals, and for any number of domains and terminals.Exemplary call flows showing the routing of incoming calls are describedin FIGS. 10 and 11 below.

The method begins when an incoming call (also referred to as aterminating call) is accepted at system 20, at a call acceptance step120. The call is destined to a particular subscriber of system 20, andthus carries the public ID (e.g., telephone number) of the subscriber.

The call may originate from any communication terminal, either fromwithin system 20 or from an external network, such as PSTN 78. In thepresent example, the call is assumed to enter network 20 via one of MSCs36, serving as a gateway MSC (GMSC). A similar sequence of steps can beused to process an incoming call that originated by another terminal 22within network 20.

The GMSC interrogates HLR 40 using the public ID, at an HLRinterrogation step 122. By interrogating the HLR, the GMSC requests theHLR to provide a routable number or network address, to which theincoming call should be routed. As explained above, CS 72 is alreadydefined in the HLR as the VLR that serves the public ID. Thus, afterbeing interrogated by the GMSC, the HLR interrogates the CS (i.e.,requests the CS to provide a routable number or address for routing thecall) using the public ID, at a CS interrogation step 124.

Redirection proxy 96 of CS 72 assigns a first temporary routable number(TRN) to the incoming call, at a first TRN allocation step 126. Theassigned TRN is associated with the CS, so that routing the call to thefirst TRN causes the call to be routed to the CS. Typically, theredirection proxy selects the first TRN out of a predetermined pool oftemporary routable numbers associated with the CS. The CS sends thefirst TRN to the HLR. Additionally, the redirection proxy associates thefirst TRN with the public ID, and caches the TRN and public ID alongwith the context of the incoming call.

HLR 40 responds to the GMSC interrogation of step 122 above, at an HLRresponse step 128. The HLR sends the first TRN assigned by redirectionproxy 96 to the GMSC. The GMSC routes the incoming call to the TRNprovided by the HLR, at a GMSC routing step 130. Since the first TRN isassociated with CS 72, the call is routed to the CS.

In some embodiments, an incoming call invokes one or more incoming callservices (T-side services). For example, if the public ID of theincoming call is a toll-free telephone number, the call causes aninvocation of a toll-free service that redirects the call to the actualphone number of the subscriber, and charges the call to the subscriber'sbill. Such service may be carried out by an SCP 44 in network 24, by aSIP AS 60 in network 28, or both. (SCPs 44 and SIP AS 60 arecollectively referred to herein as service platforms.) Another exampleof a T-side service is an interactive voice response (IVR) service, inwhich the caller interacts with predetermined voice menus carried out bya SCP 44 or AS 60.

In these embodiments, when the CS receives the incoming call routed toit by the GMSC, the CS invokes the appropriate T-side services for thiscall, at a T-side invocation step 132. Since the T-side services areinvoked responsively to the public ID carried by the incoming call,these services are invoked regardless of the terminal (private ID) towhich the call is about to be routed. T-side services are sometimesinvoked and carried out responsively to service parameters stored in theHLR.

CS 72 now determines to which of the private IDs associated with thepublic ID the incoming call is to be routed, at a terminal selectionstep 134. (In some cases, the incoming call arriving from the GMSC doesnot carry the public ID but only the TRN. However, since the associationbetween the public ID and the TRN is already cached in redirection proxy96, the proxy is able to determine the public ID and the associatedprivate IDs.)

Typically, control module 80 of CS 72 queries registry 92 in order todetermine which private ID (or IDs) is currently registered. If only oneprivate ID (terminal) is currently registered in the HLR or in registry92, the CS determines that the call should be routed to this private ID.If more than one private ID associated with the public ID is registered(i.e., more than one terminal operated by the subscriber is currentlyavailable for accepting the call), module 80 may apply any suitablebusiness logic to select to which of these private IDs to route thecall.

For example, one of the terminals may be predefined as having a higherpriority. The selected terminal may also depend on the type of the call(e.g., send SMS messages to the SIP phone and voice calls to thecellular phone). Additionally or alternatively, the selection may bebased on any suitable criteria such as time of day, user preferences,cost of calls in each of the networks, and the current load, capacityand quality of service (QoS) of each network.

In some embodiments, the decision can be made using external applicationlogic. For example, a service platform such as an application server 60may be used to determine where to route the call.

If the CS determines that the call should be routed to the cellularphone private ID, the CS interrogates the HLR using the cellular privateID, at a cellular HLR interrogation step 136. The HLR queries the S-MSCserving the Mobile terminal 32, which in turn assigns a second TRN (notto be confused with the first TRN assigned at step 126 above), at asecond TRN assignment step 138. The second TRN is associated with theprivate ID of the cellular phone. The CS routes the incoming call to thesecond TRN, thus routing the call to the cellular phone, at a cellularrouting step 140.

After completing step 140 above, the incoming call has been routed fromthe GMSC, via the CS, to the subscriber's cellular phone. It isimportant to note that the CS, by using the first TRN, remains part ofthe signaling path of the incoming call. By remaining part of thesignaling path, the CS is able to monitor the progress of the incomingcall, invoke additional services, perform hand-off, or otherwise affectthe call as needed.

If, on the other hand, the CS determines at step 134 above that the callshould be routed to the subscriber's SIP phone private ID, the CS routesthe call to the SIP phone, at a SIP phone routing step 142. In someembodiments, a routable address (such as a SIP URI) of the SIP phone hasalready been stored in registry 92 of the CS during registration of theSIP phone. (See, for example, the registration process of FIG. 5 above.)In these embodiments, the CS routes the call directly to the SIP phoneusing the routable address. In alternative embodiments, the CS routesthe call via the CSCF, which stores the routable address of the SIPphone.

Thus, the incoming call is routed from the GMSC, via the CS, to the SIPterminal. In this case too, the CS remains part of the signaling pathand is able to invoke T-side services, perform hand-offs and otherwiseaffect the progress of the call.

FIG. 7 is a flow chart that schematically illustrates a method forprocessing outgoing calls originating in system 20, in accordance withan embodiment of the present invention. The exemplary method of FIG. 7refers to outgoing calls originating from either a cellular phone 32 innetwork 24 or a SIP phone 52 in network 28. The method can be similarlyused to process outgoing calls in different types of communicationdomains and terminals, and for any number of domains and terminals. Thedestinations of outgoing calls may comprise other terminals 22 in system20 or external communication terminals, such as terminals reached overPSTN 78. Exemplary call flows showing the routing of outgoing calls aredescribed in FIGS. 12 and 13 below.

We shall first describe the processing of an outgoing call originatingfrom a cellular phone 32. The processing of a call originating from aSIP phone 52 is described further below. A cellular phone 32 initiatesan outgoing call (also referred to as an originating call) using itsprivate ID, at a cellular initiation step 150. The cellular phone isassumed to be registered in one of MSCs 36, referred to as the servingMSC(S-MSC) of this phone.

The S-MSC sends a message to the CS using the phone's private ID, at anoutgoing CS interrogation step 152. In some embodiments, the S-MSC viewsthe CS as an SCP, in accordance with the IN protocols. In theseembodiments, the message sent from the S-MSC to the CS comprises an INtrigger similar to a service invocation.

CS 72 causes the call to be routed through the CS, thus assuming controlover the call, at a CS response step 154. The redirection proxy in theCS assigns a TRN to the outgoing call and caches the association betweenthe TRN and the private ID. The CS responds to the S-MSC with a messagecomprising the TRN. The S-MSC routes the outgoing call to the CS usingthe TRN, at a MSC routing step 156.

Since the cellular phone (as well as the SIP terminal) is known to othersubscribers by its public ID, the outgoing call should carry the publicID and not the private ID. Therefore, when the CS accepts the routedoutgoing call, control module 80 replaces the private ID in the callwith the public ID, at an ID replacement step 158. The replacementeffectively hides the private ID from other subscribers and networkelements.

In some embodiments, the outgoing call carries the TRN assigned at step154 above and not the private ID itself. In these embodiments, theredirection proxy is able to determine the desired private ID using thepreviously-cached association between the TRN and the private ID.

The CS now invokes any O-side services that may be defined for theoutgoing call, at an O-side invocation step 160. Like T-side services,an O-side service may be carried out by SCPs 44 in network 24, by SIPapplication servers 60 in network 28, or both. Since the O-side servicesare invoked responsively to the newly-replaced public ID, these servicesare invoked regardless of the terminal (private ID) that originated theoutgoing call.

Normally, O-side services are invoked in accordance with a predeterminedsubscriber profile associated with the public ID. However, in someembodiments, CS 72 can notify the application servers and/or SCPs of theprivate ID being used, in order to allow for terminal capability awareservices. Notification to SCPs can be performed, for example, usingdigit processing. Notification to application servers can be performed,for example, using SIP extensions. The subscriber profile, as well asother service parameters affecting service invocation, is typicallystored in the HLR (or in another database, such as an HSS). Afterinvoking the O-side services applicable to the outgoing call, CS 72routes the call to its destination.

In an alternative embodiment to using the first TRN, terminal 32 mayinitiate a preliminary interaction with the CS, before carrying out step150 above, for example using an SMS message. Then, the terminalinitiates a call to a distinguished name (DN) associated with to the CS,thus ensuring that the call is routed through the CS and that the CSremains on the signaling path of the call.

We shall now describe the process of processing an outgoing calloriginating from a SIP phone. The method begins when a SIP phone 52initiates an outgoing call, at a SIP initiation step 164. The SIP phonecommunicates with CSCF 56. The CSCF transfers the outgoing call to theCS, at a CSCF CS transfer step 166. Typically, the CSCF views the CS asa SIP application server. In such a case, the transferring of the callis performed similarly to a service invocation. Once the outgoing callhas been transferred to the CS, the process follows steps 158-162 abovein a similar manner to the processing of calls initiated by cellularphones. The CS replaces the private ID with the public ID, invokes anyappropriate O-side services and routes the call to its destination.

Providing Unified Services

The methods and systems described herein enable a service provider tounify the services provided to subscribers of all communication domainsof system 20. Some of these subscribers may own multiple terminals indifferent communication domains, as described above. Other subscribersmay use only a single terminal in a single domain. Some aspects ofservice unification are described in PCT Patent Application PublicationWO 02/12976 A2, which is incorporated herein by reference.

In the exemplary embodiments described in FIGS. 6 and 7 above, O-sideand T-side services are invoked by CS 72, regardless of whether they arecarried out by a SCP 44 in network 24 or by a SIP application server innetwork 28. Thus, for example, a subscriber using a cellular phone innetwork 24 may be offered a service that is implemented in a SIPapplication server in network 28, and vice versa.

Furthermore, in some embodiments, services carried out by serviceplatforms in different communication domains can be invoked during asingle call. For example, an incoming call may invoke a call screeningservice running on a SIP AS in network 28, and an abbreviated dialingservice running on a SCP in network 24.

The ability to unify services across the different domains of system 20enables the service provider to avoid duplication of service platforms.When using previously-known network solutions, a service providerwishing to offer a particular service over a mobile network and a packetnetwork has to deploy separate SIP AS and SCP platforms, both runningthe same service. By contrast, the methods and systems described hereinenable the provider to deploy only a single unified service platform,either a SCP or a SIP AS, and use this platform to offer the service tosubscribers of all communication domains.

In some cases, a service provider is in the process of migrating from alegacy network to a new generation network. By unifying the servicesacross the legacy and new generation networks, the service provider isable to invest in adding services and service platforms only in the newgeneration network. The provider can minimize further investments in thelegacy network, while still offering every service of the new generationnetwork to legacy network subscribers.

Distributed GMSC Configurations

In many practical situations, a service provider operates acircuit-switched network and a packet-switched network simultaneously,often over the same geographical area. Such a situation is encountered,for example, when a service provider is in the process of migrating froma legacy circuit-switched network to a new generation network having apacket-switched backbone.

Anther example of such a situation is a virtual mobile network operator(MVNO), which owns a packet-switched network and uses it to access amobile service of another operator in order to provide wireless serviceswithout actually owning a mobile radio network.

In such situations it is often desirable to off-load signaling traffic,media traffic and processing tasks from the circuit-switched network andtransfer this load to the packet-switched network, as well as tosimplify the routing of calls. In the description that follows we shallrefer to networks 24 and 28 of FIG. 1 above as examples ofcircuit-switched and packet-switched networks, respectively. As will beshown below, deploying convergence server 72 between the two networksenables off-loading the circuit-switched network by distributing thefunctionality of the gateway MSCs (GMSCs) of the circuit-switchednetwork to other network elements. This architecture also simplifies thesignaling and call handling performed for calls destined to terminals inthe circuit-switched network.

In some known configurations that combine a circuit-switched network anda packet-switched network, an incoming call destined to a terminal inthe circuit-switched network arrives at one of media gateways (MGW) 64,often a MGW adjacent to the origin of the incoming call. In theseconfigurations, the MGW and the MGC controlling it are not aware of thedestination MSC(S-MSC) to which the incoming call should be routed,since this information is stored in the HLR. Therefore, the MGC has toforward the call to a designated gateway MSC (GMSC), which interrogatesthe HLR and determines the identity of the appropriate S-MSC. Only thenthe call can be routed to the S-MSC and to its final destination. It canbe appreciated that the resulting routing path and the sequence ofactions associated with it are often long and complicated.

Embodiments of the present invention provide improved methods and systemconfigurations for handling incoming calls destined to thecircuit-switched network that arrive at the packet-switched network. Inprinciple, in the methods described below, convergence server 72 isdeployed in conjunction with MGC 68. Since, as described above, CS 72comprises the functionality of interrogating HLR 40, the CS caninterrogate the HLR on behalf of MGC 68. CS 72 thus enables the call tobe processed without having to route the call to, or otherwise use, anygateway switching element of the circuit-switched network, such as aGMSC.

FIGS. 8A and 8B are block diagrams that schematically illustratedistributed GMSC configurations, in accordance with embodiments of thepresent invention.

FIG. 8A shows a distributed system configuration 174, in accordance withan embodiment of the present invention. In this configuration,convergence server 72 is deployed in conjunction with MGC 68. Thefunctionality of CS 72 in interrogating HLR 40 and routing incomingcalls is similar to the functionality described in FIG. 6 above. Note,however, that the use of public and private IDs is not mandatory in thepresent context.

When an incoming call destined to a destination terminal of thecircuit-switched network arrives, the signaling information (denoted Sin the figures) of the incoming call is provided directly to MGC 68. Thevoice content of the call, denoted V, or other media content, isprovided directly to MGW 64A, typically in the vicinity of the point inwhich the call enters system 174. Note that although the incoming callarrives into the packet-switched network, the call itself is notnecessarily a packet-switched call. For example, the signaling of theincoming call may comprise SS7 signaling.

The MGC views CS 72 as a standard application server, and sends thesignaling of the incoming call to the CS (e.g., via SIP signaling). CS72 interrogates HLR 40 and obtains from the HLR the necessary routinginformation for routing the call in the circuit-switched network. Asdescribed in FIG. 6 above, the CS receives a TRN from the HLR and sendsthe TRN to the MGC via signaling. This message appears to the MGC as ifan application server has changed the destination of the call. Thesignaling is then routed to S-MSC 36, as instructed by the HLR. MGC 68instructs MGW 64A to route the voice content over the IP backbone of thepacket-switched network to MGW 64B, from which it is routed to S-MSC 36and to the destination terminal.

It can be seen that no GMSC participates in the process. In effect, thefunctionality of the gateway MSC has been distributed between MGC 68 andCS 72. As a result, the processing and communication handling requiredfrom the GMSCs in the network is significantly reduced. Thus, GMSCresources are freed and can be used for other functions, such as forserving as S-MSC for other calls. The method further simplifies therouting paths used for routing incoming calls.

In some embodiments, CS 72 may receive from the HLR an indicationregarding call services that should be provided to the incoming call. Inthese embodiments, CS 72 invokes the appropriate service platform, whichmay comprise a SCP 44, an AS 60 or both, to provide the call services tothe call. Additionally or alternatively, some call services (e.g., acall forwarding service) may relate to the routing of the call. For suchservices, CS 72 may perform the appropriate routing internally withoutinvoking an external service platform.

FIG. 8B shows a network configuration 178, in accordance with analternative embodiment of the present invention. In this configuration,the incoming call comprises a packet-switched call, such as a callarriving from an external SIP terminal or SIP trunk. Such a scenario isencountered, for example, when networks 24 and 28 are interconnectedwith an external packet-switched network.

The signaling information of the incoming call is routed directly to MGC68. CS 72 interrogates the HLR and provides the appropriate routinginformation to MGC 68. The MGC routes the signaling information to S-MSC36 and on to the destination terminal. The voice content of the incomingcall is routed, as instructed by MGC 68, to MGW 64B and from there toS-MSC 36 and to the destination terminal. In the exemplary configurationof network 178, the call arrives directly to MGW 64B, thus MGW 64A doesnot participate in the call handling process.

In some embodiments, the circuit-switched network comprises multiplecommunication domains conforming to different protocols, each comprisinga separate HLR and one or more GMSCs. In these embodiments, CS 72 caninterrogate the appropriate HLR out of the multiple HLRs, thus avoidingthe call from being routed to the multiple GMSCs. For example, thecircuit-switched network may comprise a cellular network comprising aCDMA segment and a GSM segment. FIG. 8B shows two HLRs denoted 40A and40B, both interrogated by CS 72.

The exemplary configurations shown in FIGS. 8A and 8B refer to a singleincoming voice call handled by a small number of MSCs and mediagateways. These configurations were chosen purely for the sake ofconceptual clarity. The methods and systems described herein can besimilarly used to handle other types of calls comprising signaling andmedia content, such as multimedia sessions. These methods and systemscan be used in networks having a higher number of MSCs and/or MGWs.Typically, the benefit of distributing the functionality of gateway MSCsincreases with growing network complexity.

An exemplary application of configurations 174 and 178 is enabling amobile virtual network operator (MVNO) to use a wireless network ofanother service provider. Assume that the systems shown in FIGS. 8A-8Ccomprise wireless networks. The incoming calls comprise callsoriginating from a MVNO that provides connectivity and services tosubscribers without actually owning a wireless network. Thus, MGC 68 andCS 72 jointly function similarly to a GMSC that allows calls originatingfrom the MVNO to be processed by the wireless network.

FIG. 9 is a call-flow diagram that schematically illustrates a methodfor processing an incoming call using a distributed GMSC configuration,such as the configurations of FIGS. 8A and 8B above, in accordance withan embodiment of the present invention. The call flow begins with thesignaling of an incoming call arriving at MGC 68. (The figure refers tothe signaling of the call. As explained above, the voice content of thecall arrives at one of MGW 64.)

MGC 68 sends the call to CS 72, which typically acknowledges theacceptance of the call. CS 72 interrogates HLR 40 in order to determinewhich call services should be provided to the incoming call. The HLRreturns a list of services and parameters, such as an IN trigger list.The CS invokes the requested services by invoking the appropriate SCP44. Using this technique, the T-side services previously provided by thegateway MSC can now be provided by the CS.

CS 72 now interrogates HLR 44 again, this time in order to request a TRNto which to route the incoming call. The HLR in turn interrogates theS-MSC and sends the TRN sent by the S-MSC to the CS. The CS mayoptionally invoke SCP 44 again. The CS sends the TRN to the MGC, whichtypically acknowledges. The MGC then uses the TRN to route the incomingcall to the destination terminal via the S-MSC. In this exemplary callflow, the CS remains part of the signaling path of the call, so that itmay continue to provide call services during the call.

Call Flow Examples

The following section provides additional exemplary call flows, in orderto demonstrate several aspects of the methods and systems describedabove.

FIG. 10 is a call-flow diagram that schematically illustrates a methodfor processing incoming calls destined to a cellular phone 32 incircuit-switched mobile network 24, in accordance with an embodiment ofthe present invention. The call flow follows the principles described inFIG. 6 above. The method begins with an incoming call arriving via agateway MSC of network 24. The GMSC interrogates HLR 40, in order todetermine which call services should be provided to the incoming call.The HLR responds with a list of services and service parameters, such asusing an IN trigger list.

Using the list, The GMSC invokes the appropriate SCP 44 to provide thedesired call services. The GMSC interrogates the HLR again, this time inorder to determine the routing of the incoming call. The HLRinterrogates the CS, and the CS sends the HLR a TRN (denoted CS TRN),causing the call to be forwarded to the CS. The HLR provides the CS TRNto the GMSC.

Optionally, the GMSC may choose to invoke SCP 44 again. Then, the GMSCbegins a process of routing the call to the CS. In some embodiments, forexample in order to simplify future hand-off processes, the routing ofthe call also passes through the CSCF. This process is referred to asanchoring the call at the CSCF. The CS may optionally choose to invokeadditional services carried out by SIP AS 60 in network 28.

Until now, the messages exchanged in the network and the invokedservices carried the public ID. At this stage, it is assumed that the CSdetermines that the private ID selected for routing the call is thecellular private ID. (A flow call that describes routing of an incomingcall to a SIP terminal is shown in FIG. 11 below.) The CS interrogatesthe HLR with the cellular private ID. The HLR communicates with theS-MSC of the destination cellular phone and requests a TRN in order toroute the call to the S-MSC. The S-MSC responds with a TRN (denotedS-MSC TRN). The HLR sends the S-MSC TRN to the CS, which in turn routesthe call via the MGC, CSCF and S-MSC to the destination cellular phone.

FIG. 11 is a call-flow diagram that schematically illustrates a methodfor processing incoming calls destined to a SIP terminal 52 inpacket-switched network 28, in accordance with an embodiment of thepresent invention. The call flow follows the principles described inFIG. 6 above. The method begins with an incoming call arriving via aGMSC. The initial stags of the call flow are similar to the flow of FIG.10 above. In the present example, however, after anchoring the call atthe CSCF and optionally invoking SIP AS 60, it is assumed that the CSdetermines that the private ID selected for routing the call is the SIPprivate ID. Therefore, the CS routes the call via the CSCF to thedestination SIP terminal.

FIG. 12 is a call-flow diagram that schematically illustrates a methodfor processing outgoing calls initiated by a cellular phone 32 in mobilenetwork 24, in accordance with an embodiment of the present invention.The call flow follows the principles described in FIG. 7 above. Themethod begins with phone 32 initiating an outgoing call. The call,carrying the phone's private ID, is sent to the S-MSC serving phone 32.The S-MSC requests and receives a CS TRN from CS 72. The S-MSC routesthe call to the CS using the CS TRN. As explained above, the call isrouted (“anchored”) via the CSCF and MGC.

All the above messages carry the cellular private ID. At this stage, theCS replaces the private ID with the public ID in the outgoing call. TheCS may invoke SCP 44 and/or SIP AS 60 to provide O-side services to theoutgoing call, based on the public ID. The CS routes the call via theCSCF and MGC to its destination, in this example over PSTN 78.

FIG. 13 is a call-flow diagram that schematically illustrates a methodfor processing outgoing calls initiated by a SIP terminal 52 inpacket-switched network 28, in accordance with an embodiment of thepresent invention. The call flow follows the principles described inFIG. 7 above. In the present example, the call is destined to a cellularphone 32 in network 24. The method begins with SIP terminal 52initiating a call carrying the SIP private ID to CSCF 56. The CSCFroutes the call to CS 72, which replaces the originating SIP private IDwith the corresponding public ID. Optionally, CS 72 activates O-sideservices by invoking SCP 44 and/or SIP AS 60.

The CS interrogates the HLR, in order to check which services should beprovided to the termination side of the call (which in this examplecomprises a cellular phone 24). As a result of this interrogation, CS 72may invoke SCP 44 to provide the appropriate T-side services.

The CS now interrogates the HLR in order to determine the routing of theoutgoing call. The ILR requests and accepts a S-MSC TRN from the S-MSCserving the destination phone 24. The HLR sends the S-MSC TRN to CS 72.CS 72 may optionally choose to activate SCP 44 again. The CS then routesthe call to the S-MSC using the S-MSC TRN.

FIG. 14 is a call-flow diagram that schematically illustrates theprocessing of SMS messages, in accordance with an embodiment of thepresent invention. The figure is divided into the following foursub-processes:

-   -   Processing of an SMS message sent from network 24 to an        application server (AS) that handles SMS in network 28.    -   Processing of an SMS message sent from a SIP terminal in network        28 to the application server.    -   Processing of an SMS message sent from the application server to        a cellular phone 32 in network 24.    -   Processing of an SMS message sent from the application server to        a SIP terminal in network 28.

The four sub-processes can be combined in any suitable order. Forexample, the second sub-process followed by the third sub-processdescribe the processing of an SMS message sent from a SIP terminal to acellular phone.

Sending an SMS message from network 24 to AS 60 begins with the messagebeing provided to SMS center (SMSC) 48. The message may originate from acellular phone 24 or from any other suitable source, such as a web-basedmessaging service connected to SMSC 48, as is known in the art. SMSC 48sends the SMS message to CS 72 using the originating private ID. The CSreplaces the private ID with the public ID and forwards the message toAS 60. AS 60 sends an acknowledgement to CS 72 and CS 72 sends anacknowledgement to SMSC 48.

Sending an SMS message from SIP terminal 52 in network 28 to AS 60begins with the SIP terminal sending the message to CS 72, which the CSacknowledges. CS 72 then replaces the private ID in the message with thepublic ID, and sends the message to AS 60. AS 60 sends anacknowledgement to CS 72, which in turn acknowledges to SIP terminal 52.

Sending an SMS message from AS 60 to a destination cellular phone 32begins with AS 60 sending the message to CS 72. The message carries theterminating public ID. The CS selects the private ID to which themessage is to be sent, in this example the cellular private ID. The CSinterrogates HLR 40 in order to obtain the identity of the MSC servingthe destination cellular phone. The HLR responds and provides therouting address of the MSC. The CS then sends the SMS message to theMSC, to be forwarded to the destination cellular phone. The procedure iscompleted with the MSC sending an acknowledgement to CS 72, and CS 72sending an acknowledgement to AS 60.

Sending an SMS message from AS 60 to a destination SIP terminal 52begins with AS 60 sending the message to CS 72. The message carries thepublic ID. The CS selects the private ID to which the message is to besent, in this example the SIP private ID. The CS sends the message tothe destination SIP terminal. The procedure is completed with the SIPterminal sending an acknowledgement to CS 72, and CS 72 sending anacknowledgement to AS 60.

Note that in the processing of SMS messages, unlike voice calls, thesignaling and data go through the same path. Therefore, it is generallyunnecessary to use the TRN mechanism when processing SMS messages. Oncethe SMS message is forwarded to its destination, the process isconsidered completed.

Hand-Off Procedures

FIGS. 15 and 16 are call-flow diagrams that schematically illustratemethods for handing-off calls, in accordance with embodiments of thepresent invention. In the present example, the assumption is that aparticular dual-mode terminal comprises a cellular phone 32 and a Wi-FiSIP terminal 52. FIG. 15 describes an exemplary hand-off procedure forhanding off an active call from the SIP terminal to the cellular phone.A hand-off procedure from the cellular phone to the SIP phone isdescribed in FIG. 16 further below.

The method of FIG. 15 begins in a situation in which an active callexists between the Wi-Fi SIP terminal of the dual-mode terminal andbetween a third terminal, in this example over PSTN 78. In principle,the hand-off process comprises three stages: (1) initiating a new callfrom the cellular phone of the dual-mode terminal to the CS in parallelto the existing SIP call, (2) connecting the new call to the thirdterminal and (3) terminating the original call with the SIP terminal.

In some embodiments, cellular phone 32 initiates the new call to astatic number associated with the CS. The static number is dedicated tohand-off procedures. Therefore, whenever the CS accepts a call to thisnumber, it concludes that the call is part of a hand-off process andtreats it accordingly. The CS optionally updates SIP AS 60 regarding thehand-off process in progress.

The cellular phone of the dual-mode terminal initiates a cellular callwith the third terminal via the S-MSC serving phone 32. The CS thenconnects the two cellular calls (the call between phone 32 and the CSand the call between the CS and the third terminal) to produce the newcall between phone 32 and the third terminal. Having established the newcall, the CS terminates the SIP call.

FIG. 16 describes an exemplary hand-off procedure for handing off anactive call from the cellular phone to the SIP terminal. The method ofFIG. 16 begins in a situation in which an active call exists between thecellular phone of the dual-mode terminal and between a third terminal,in this example over PSTN 78. In principle, the hand-off processcomprises three stages: (1) initiating a new SIP call from the SIPterminal of the dual-mode terminal to the CS in parallel to the existingcellular call, (2) connecting the new SIP call to the third terminal and(3) terminating the original cellular call.

The SIP terminal of the dual-mode terminal initiates a new SIP call.Similarly to the process of FIG. 14 above, the new SIP call is destinedto a static number associated with the CS, which is dedicated tohand-off processes. The CS may choose to update SIP AS 60 regarding thehand-off process. The CS connects the call to the third terminal via theCSCF and terminates the original cellular call.

It will be appreciated that the embodiments described above are cited byway of example, and that the present invention is not limited to whathas been particularly shown and described hereinabove. Rather, the scopeof the present invention includes both combinations and sub-combinationsof the various features described hereinabove, as well as variations andmodifications thereof which would occur to persons skilled in the artupon reading the foregoing description and which are not disclosed inthe prior art.

1-42. (canceled)
 43. A computer-implemented method for communicationover circuit-switched and packet-switched networks, comprising:accepting, at a media gateway controller (MGC) connected to thecircuit-switched and packet-switched networks, signaling of a calladdressed to a destination terminal in the circuit-switched network;responsively to the signaling, interrogating a home location register(HLR) of the circuit-switched network without using any gatewayswitching element of the circuit-switched network so as to provide tothe MGC routing information enabling routing of the call to a servingswitching element of the circuit-switched network that serves thedestination terminal; and based on the provided routing information,routing the call using the MGC to the destination terminal via theserving switching element.
 44. The method according to claim 43, whereinthe circuit-switched network comprises a mobile circuit-switchednetwork.
 45. The method according to claim 43, and comprising acceptinga media content of the call at a media gateway. (MGW) controlled by theMGC and connected to the circuit-switched and packet-switched networks,and wherein routing the call comprises causing the MGW to route themedia content to the destination terminal via the serving switchingelement.
 46. The method according to claim 43, wherein interrogating theHLR comprises accepting from the HLR a temporary routable number (TRN)associated with the serving switching element, and wherein routing thecall comprises causing the MGC to route the call to the TRN.
 47. Themethod according to claim 43, wherein the circuit-switched networkcomprises first and second sub-networks comprising respective first andsecond HLRs, and wherein interrogating the HLR comprises determining oneof the first and second sub-networks with which the destination terminalis associated, and interrogating a corresponding one of the first andsecond HLRs.
 48. The method according to claim 47, wherein the firstsub-network conforms to a first communication protocol and wherein thesecond sub-network conforms to a second communication protocol differentfrom the first communication protocol.
 49. The method according to claim43, wherein interrogating the HLR comprises accepting from the HLR anindication of a call service to be provided to the call, and invoking aservice platform to provide the call service.
 50. The method accordingto claim 49, wherein invoking the service platform comprises invoking atleast one of a service control point (SCP) in the circuit-switchednetwork and an application server (AS) in the packet-switched network.51. The method according to claim 43, wherein interrogating the HLRcomprises accepting from the HLR an indication of a call servicecomprising a routing operation to be performed on the call, andperforming the routing operation responsively to the indication.
 52. Aconvergence server, comprising: a network interface, which is arrangedto communicate with a circuit-switched network, a packet-switchednetwork and a media gateway controller (MGC) connected to thecircuit-switched and packet-switched networks; and a processor, which isarranged to interrogate a home location register (HLR) of thecircuit-switched network responsively to signaling of a call accepted bythe MGC over the packet-switched network, the call addressed to adestination terminal in the circuit-switched network so as to provide tothe MGC, without using any gateway switching element of thecircuit-switched network, routing information enabling routing of thecall to a serving switching element of the circuit-switched network thatserves the destination terminal and, based on the provided routinginformation, to route the call using the MGC to the destination terminalvia the serving switching element.
 53. The convergence server accordingto claim 52, wherein the circuit-switched network comprises a mobilecircuit-switched network.
 54. The convergence server according to claim52, wherein a media content of the call is accepted at a media gateway(MGW) controlled by the MGC and connected to the circuit-switched andpacket-switched networks, and wherein the processor is arranged to causethe MGC to route the media content to the destination terminal via theserving switching element responsively to the routing informationprovided to the MGC.
 55. The convergence server according to claim 52,wherein the processor is arranged to accept from the HLR a temporaryroutable number (TRN) associated with the serving switching element, andto cause the MGC to route the call to the TRN.
 56. The convergenceserver according to claim 52, wherein the circuit-switched networkcomprises first and second sub-networks comprising respective first andsecond HLRs, and wherein the processor is arranged to determine one ofthe first and second sub-networks with which the destination terminal isassociated, and to interrogate a corresponding one of the first andsecond HLRs.
 57. The convergence server according to claim 56, whereinthe first sub-network conforms to a first communication protocol andwherein the second sub-network conforms to a second communicationprotocol different from the first communication protocol.
 58. Theconvergence server according to claim 52, wherein the processor isarranged to accept from the HLR an indication of a call service to beprovided to the call and to invoke a service platform to provide thecall service.
 59. The convergence server according to claim 58, whereinthe processor is arranged to invoke at least one of a service controlpoint (SCP) in the circuit-switched network and an application server(AS) in the packet-switched network so as to provide the call service.60. The convergence server according to claim 52, wherein the processoris arranged to accept from the HLR an indication of a call servicecomprising a routing operation to be performed on the call, and toperform the routing operation responsively to the indication.
 61. Acommunication system, comprising: a circuit-switched network; apacket-switched network; a media gateway controller (MGC) connected tothe circuit-switched and packet-switched networks, which is arranged toaccept signaling of a call over the packet-switched network, the calladdressed to a destination terminal in the circuit-switched network, andto route the call to the destination terminal; and a convergence serverconnected to the MGC and to the circuit-switched and packet-switchednetworks, which is arranged to interrogate a home location register(HLR) of the circuit-switched network responsively to the signaling ofthe call without using any gateway switching element of thecircuit-switched network, so as to provide to the MGC routinginformation enabling routing of the call to a serving switching elementof the circuit-switched network that serves the destination terminal,and, based on the provided routing information, to route the call usingthe MGC to the destination terminal via the serving switching element.62. A computer software product for communication over circuit-switchedand packet-switched networks, the product comprising a computer-readablemedium, in which program instructions are stored, which instructions,when read by a computer, cause the computer to interrogate a homelocation register (HLR) of the circuit-switched network responsively tosignaling of a call accepted by a media gateway controller (MGC) overthe packet-switched network, the call addressed to a destinationterminal in the circuit-switched network, so as to provide to the MGC,without using any gateway switching element of the circuit-switchednetwork, routing information enabling routing of the call to a servingswitching element of the circuit-switched network that serves thedestination terminal and, based on the provided routing information, toroute the call using the MGC to the destination terminal via the servingswitching element.